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ABSTRACT 

The NASA Glenn Research Center is investigating and 
developing suitable reconfigurable radio architectures for 
future NASA missions. This effort is examining software- 
based open-architectures for space based transceivers, as 
well as common hardware platform architectures. The Joint 
Tactical Radio System’s (JTRS) Software Communications 
Architecture (SCA) is a candidate for the software 
approach, but may need modifications or adaptations for use 
in space. An in-house SCA compliant waveform 
development focuses on increasing understanding of 
software defined radio architectures and more specifically 
the JTRS SCA. Space requirements put a premium on size, 
mass, and power. This waveform development effort is key 
to evaluating tradeoffs with the SCA for space applications. 

Existing NASA telemetry links, as well as Space 
Exploration Initiative scenarios, are the basis for defining 
the waveform requirements. Modeling and simulations 
are being developed to determine signal processing 
requirements associated with a waveform and a mission- 
specific computational burden. Implementation of the 
waveform on a laboratory software defined radio platform is 
proceeding in an iterative fashion. Parallel top-down and 
bottom-up design approaches are employed. 

1. INTRODUCTION 

A software defined radio SCA waveform development effort 
is underway at the NASA Glenn Research Center (GRC). 


This is a waveform based on existing space telemetry 
waveforms currently being used by NASA. Presently it is an 
in-house laboratory implementation and may be demonstrated 
over a satellite link at a later time. All functions, with the 
exception of radio frequency (RF) up and down conversion 
are being implemented on a commercially available software 
defined radio development platform. 

Developing an SCA compliant software defined radio 
waveform is aiding NASA’s assessment of the SCA’s 
applicability to space in general and to mission scenarios in 
particular. These efforts are part of the larger Space 
Telecommunications Radio System program currently 
underway to define NASA’s future communications system 
architecture. Software defined radio for space is attractive, 
as in many terrestrial applications, because of the inherent 
reconfigurability which enhances capability. Also, there 
may be cost savings through software reuse and waveform 
portability. Use of the open-architecture SCA (or a modified 
version) could bring substantial benefit to NASA. However, 
hardware constraints (i.e., power, size, mass, radiation 
tolerant/hardened components) for space platforms make 
implementation of such an architecture challenging. 

The waveform requirements will be presented first in 
this paper, with some explanation of the major parameter 
selections. Secondly, the modeling and simulation efforts 
will be described. Thirdly, the top-down design approach is 
briefly described, followed by the implementation progress 
with the target platform bottom-up design. Due to the 
complexity of the SCA and the software radio development 
platform, a top-down design process is used. However, the 
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waveform functions and specifications being implemented 
require a bottom-up viewpoint as well. Finally, SCA 
transformation of the waveform is discussed. 

2. WAVEFORM REQUIREMENTS 

Selecting the waveform to develop was a process that had 
several considerations. In general, the goal is for the 
waveform to be representative of NASA communications 
and able to fit in a future open architecture. It started with a 
look at existing NASA waveforms in the NASA Ground 
Network, Space Network, and Deep Space Mission System 
[1]. Future waveforms are also considered, such as those for 
the Space Exploration Initiative, (although these overall 
scenarios are still being developed themselves). Also 
considered are verification and demonstration possibilities 
with existing hardware and communications infrastructure 
at NASA GRC. 

A telemetry type waveform was targeted because it is 
usually a lower data rate, relative to a science return link, 
and because it is a prevalent type. From the telemetry 
waveforms studied the most important common parameters 
were selected and values chosen, as detailed in Table 1. 
Some of the waveform specifications are based on the 
Consultative Committee for Space Data Systems (CCSDS) 
recommendations. The basic parameters defined are data 
rate, modulation, coding scheme, samples/symbol, baseband 
data interface, Intermediate Frequency (IF) interface, 
scrambling scheme, and bandwidth. Currently there are no 
RF parameters listed, such as carrier frequency, but these 
will be defined as needed with a simulated or real link 


Table 1: Waveform parameters 


Parameter 

Value 

Raw Data Rate 

1 Mbps 

User Data Rate 

< 1 Mbps 

Carrier Modulation 

QPSK 

Samples/Symbol 

>4 

Encoding 

Convolutional (Rate-14) 

Reed-Solomon 

OPTIONAL 

Decoding 

maximum-likelihood 

(Viterbi) 

Reed-Solomon 

OPTIONAL 

Baseband Data 
F ormat/Interface 

Serial (Clock and Data) 
NRZ-L, LVTTL 

OPTIONAL - Ethernet 

Pseudo-Randomizer 
Or scrambler 

IESS 308, 

CCITT V.35, or CCSDS 

Implementation Loss 

< 0.5 dB 

Bandwidth 

<2 MHz 

IF 

70 MHz 


demonstration. Initially the RF components of the 
demonstration will be fixed or manually reconfigurable 
frequency components, and therefore not software defined. 

The data rate of less or equal to one mega bits per 
second (Mbps) will allow the majority of signal processing 
functions to be implemented in software. This allows for a 
mostly General Purpose Processor (GPP) implementation, 
the ideal for portability and SCA implementation. The user 
data rate will be lower than 1 Mbps, depending on the 
coding overhead. NASA is interested in higher data rates, 
however, and this waveform effort is intended to be scalable 
(with appropriate implementation changes). 

3. WAVEFORM SIMULATIONS 

A model of the waveform using computer simulation tools 
was created to complement and assist the development in 
several ways. First, the model provides a means to simulate 
performance from a communications standpoint, and thus 
aid in development and debugging. More specific to a 
software defined radio waveform, the model is being used 
to estimate signal processing and functional requirements 
associated with a waveform and a mission-specific 
computational burden. The advantages and disadvantages of 
allocating functions on a specific hardware platform versus 
other platforms can then be compared. 

Waveform modeling and simulations are being 
developed using MATLAB/SIMULINK, Xilinx/System 
Generator and C/C++ programming software tools. These 
design tools provide system analysis, enhanced signal 
processing, and re-hosting of existing signal processing 
functions to new hardware or software platforms. 

As Figure 1 shows, the waveform simulation model 
contains most of the critical functions, such as modulation 
and demodulation, encoding and decoding, filtering, and 
synchronization. The current model consists of gray coded 
quadrature phase shift keying (QPSK) for modulation and 
demodulation techniques; rate 14 convolutional code with a 
constraint length of K = 7 and a three-bit soft decision 
maximum-likelihood (Viterbi) decoding for error correction 
techniques; square-root raised cosine digital filters with a 
roll-off factor of 0.5 used to shape a signal; and an Additive 
White Gaussian Noise (AWGN) with zero mean and power 
spectral density N/2 used to characterize the channel 
condition. The synchronization technique is being 
implemented based on the CCSDS recommendation. A 
pseudo-random number generator is used to produce input 
data binary signal sequences with sufficient randomness. A 
bit-error-rate (BER) measurement is used to evaluate the 
performance of the system. Functional behaviors of the 
simulation models are being tested and verified using 
AWGN channel condition and BER performance. 

The goal of software radio is to provide a maximum 
flexibility for a radio platform [2]. One of the limitations of 
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Figure 1: Waveform simulation model 


any SDR implementation is digital processing flexibility 
and capacity. The digital hardware architecture focuses on 
the mix of parallelism and pipelining of the digital signal 
processing hardware from Application Specific Integrated 
Circuits (ASICs) and Field Programmable Gate Arrays 
(FPGAs) to Digital Signal Processors (DSPs) and GPPs. 
One argues that FPGAs are the best choice given the high 
cost of ASICs and the high power dissipation per function 
of DSPs. FPGAs are a high-speed configurable logic 
circuits packaged as high-density commodity chips. DSPs 
are designed for efficient execution of computationally 
intense functions like fast Fourier transforms. 

The advantages of allocating functions on a specific 
hardware component are being analyzed based on power 
consumption, processing capability, and reconfigurability. 
The core digital signal processing can be implemented 
through GPP, FPGA, ASIC and DSP hardware. Typically a 
GPP offers maximum flexibility but high power 
consumption, and low computational rate. In contrast, an 
ASIC provides lower power consumption and higher 
computational rate, but minimal flexibility. However, an 
ASIC offers the most radiation hardening options. A DSP 
provides higher computational rate than the GPP with 
comparable power consumption. FPGAs may be found 
somewhere between ASICs and DSPs regarding these 
characteristics. 

The selection of the core computing elements depends 
on the algorithms/functions and their computational 
throughput requirements. For example, a high-rate 
waveform is typically implemented on a DSP-based or 
FPGA-based platform, whereas a low-rate waveform is 
implemented on GPP-based platform. For space 


applications, architectures that offer a mix of ASIC, FPGA, 
DSP and GPP components allow the best combination of 
reconfigurability with manageable power consumption and 
high processing capacity. In addition, the mix of computing 
elements allows radiation hard components to aid non- 
radiation hard elements with mitigation techniques. 

4. TOP-DOWN DESIGN 

The top-down waveform design begins with disseminating 
the tasks required for the application to transform the data 
from input to output. In the case of the receiver this would 
be all the functions required to take the raw data from the 
Analog-to-Digital Converter (ADC) and transform 
(i.e., downconvert, track, filter, demodulate, decode) data to 
an expected output baseband format. The functions are 
grouped together into high level components based on the 
ISO 7-layer reference model and the signal flow; functions 
such as MODEM, Physical Layer, MAC Layer, Link Layer, 
etc. Support functions not directly related to the signal path 
such as user interfaces, logging, diagnostics, etc. will be 
services supplied by the operating environment, or as in the 
case of the user interface will be a component of the 
waveform. The high level design determines how the 
various parts of the waveform are connected and what 
interfaces are exposed by each component. This high level 
view is further refined into the application programming 
interfaces (APIs) required to implement the waveform at the 
various levels as well as the CORBA IDL that will connect 
the components. The global use-case shown in Figure 2 
depicts entities the waveform application interacts with as 
stick figures and the main use-cases as ovals. 
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Figure 2: Telemetry waveform global use-case 

The output of the modeling and simulation will help 
determine which software components will be implemented 
on general purpose processors GPPs, DSPs, or FPGAs. In 
the case of DSPs and FPGAs there will be adaptors to allow 
these parts to interface with other software components. 

5. TARGET PLATFORM 

Waveform implementation has been carried out on the 
SDR-3000, a software defined radio development system 
from Spectrum Signal Processing, pictured in Figure 3. This 
target platform has FPGAs and DSP/GPPs, as well as 
Digital-to-Analog Converters (DACs) and ADCs all 
integrated with high-speed switched fabric. Although this is 
the specific target platform for the initial development, the 
goal of the waveform design is to keep the development as 
modular and portable as possible. With this in mind, efforts 
have been underway to implement as many waveform 
functions as possible in the GPP devices. Software modules 
will be inherently more portable than FPGA firmware 
modules based on the nature of the SCA, (version 2.2 
specifically; the latest 3.0 extensions may be utilized in the 
future). Figure 4 shows the functional data flow for the 
waveform, as well as the targeted component type for each 


function. Only the digital IF up conversion on the transmit 
side is considered to require an FPGA’s speed. Whereas on 
the receive side a few other functions will need an FPGA 
implementation in addition to the down conversion. All 
other functions are being implemented in the DSP/GPPs. 

A transmit version of the waveform is under way, with 
the modulation, up conversion, and DAC functions. This 
portion is being converted to an SCA version first to 
establish the process before the other functions are 
developed. 

6. TRANSFORMATION TO SCA 

For any software radio platform making a waveform SCA 
compliant is a challenging task. At GRC an incremental and 
iterative approach is taken to transforming the waveform to 
SCA compliance, (version 2.2). As mentioned in the 
previous section, only a simplified transmit function is 
being developed with the first iteration. The lessons learned 
are accelerating implementation of subsequent waveform 
functions as the full SCA waveform is incrementally built. 

The SCA describes a software environment with a set 
of interfaces and services. Together these interfaces and 
services provide a core framework for a software defined 
radio. The software radio runs waveform applications that 
can simply be thought of as a collections of processing 
devices connected together to achieve some signal 
processing. There are three key elements to the development 
of an SCA compliant waveform: 1) processing devices 
2) connections between the devices 3) deployment and 
control. 

The processing devices and the corresponding 
connections for our NASA waveform have been 
determined. To become SCA compliant, the waveform must 
be able to operate within the core framework of the SCA. 
For this effort we are using the Harris core framework to 



Figure 3: Target platform SDR-3000 (top) with 
development PC (bottom) 
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Figure 4: Functional data flow and implementation targets 

provide the deployment and control of our waveform. 
Deployment of the waveform is accomplished by the 
AppliccitionFactory and Application objects in the Harris 
core framework. Overall control of the waveform is 
primarily accomplished through the DomainManager object 
in the core framework. Supporting services for the 
waveform file systems and logging capabilities are also 
provided by the Harris core framework. 

To deploy the application, the DomainManager sends a 
request to the ApplicationFactory to instantiate a specific 
Application. The created application can then be 
configured and controlled by the DomainManager. The 
DomainManager provides three categories of control: 

1) Human Computer Interface 2) Registering and un- 
registering software components needed to manage the 
various processing devices 3) Core framework 
administration. 

In order to connect the various components of the 
waveform and to operate within the Harris core framework, 
waveform developers must ensure that components interact 
with the core framework through the interfaces as 
specified in the SCA. The GRC team is starting to 
implement code for the following needed interfaces: 
Port, LifeCycle, TestableObject, PropertySet, PortSupplier, 
ResonrceFactory and Resource. [3] 

Besides communicating with each other, the processing 
devices also need to communicate with various parts of the 


core framework. Thus logical devices must be implemented 
in software with appropriate SCA interfaces. A logical 
device acts as a bridge between hardware devices and the 
core framework. Various device interfaces such as Device, 
LoadableDevice, ExecutableDevice and DeviceManager are 
being employed for this space telemetry SCA waveform. 

To bring the components together the SCA defines a set 
of files which describes the waveform in terms of the 
components and the connections between the components. 
This set of files consists of ASCII text and is called the 
waveform’s domain profile. These files describe the 
identity, capabilities, properties, inter-dependencies and 
location of the hardware devices and software components 
that make up the system. All the descriptive data about a 
system is expressed in XML vocabulary. For the GRC space 
telemetry waveform, the following XML files are being 
developed: Software Assembly Descriptor, Software 

Package Descriptor, Software Component Descriptor, 
Property Files, and Domain Manager Configuration 
Descriptor [4]. 

An underlying part of the SCA operating environment 
consists of CORBA middleware. And thus code 
development for SCA compliance relies on understanding 
CORBA, the associated IDL interfaces along with a general 
knowledge of distributed processing. Working within the 
SCA core framework is a complicated matter that requires 
considerable time to gain the experience to completely 
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understand the process of making an SCA compliant 
waveform. However, a more thorough understanding of the 
SCA will allow an accurate assessment of its applicability to 
space and future NASA waveforms. 

7. CONTINUING WORK 

The uniqueness of the space environment is the 
differentiating viewpoint from which this work continues. 
Development of the complete SCA waveform will continue 
to allow valid comparisons to a functionally equivalent non- 
SCA waveform. Both waveforms will be running on the 
same software defined radio platform. Also, future work 
will compare this mostly GPP implementation approach 
with an all FPGA approach. Resource requirements 


(i.e. size, mass, power) for equal waveform performance 
will be evaluated. Overall, this waveform effort is building 
knowledge and experience for the next NASA space 
telecommunications radio system architecture. 
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